Docker 容器构建

这就意味着 CMD 和 RUN 命令中不能使用字符串，不能这么写:

FROM scratch
COPY --from=0 /go/hello .
CMD ./hello

如果用以上命令构建镜像，并将其运行为容器，就会遇到下面的报错:

docker: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"/bin/sh\": stat /bin/sh: no such file or directory": unknown.

从报错信息可以看出，镜像中并不包含 /bin/sh，所以无法运行程序。

因为在 CMD, RUN 命令中使用字符串作为参数时，这些参数会被放到 /bin/sh 中执行，也就是说，下面这两条语句是等效的:

• CMD ./hello
• CMD /bin/sh -c "./hello"

解决办法是: 使用 JSON 语法取代字符串语法 。

比如，将 CMD ./hello 替换为 CMD ["./hello"] 。

scratch 镜像不包含任何调试工具。ls, ps, ping, shell 都没有。

无法使用 docker exec 进入容器，也无法查看网络堆栈信息等等。

1. 查看容器中的文件，可以使用 docker cp ；
2. 查看或调试网络堆栈，可以使用 docker run --net container 或者使用 nsenter ；
3. 为了更好地调试容器，Kubernetes 也引入了一个新概念叫 Ephemeral Containers ，但现在还是 Alpha 特性。

虽然有这些方法可以调试容器，但它们比较麻烦。

折中一下可以选择 busybox 或 alpine 镜像来替代 scratch。

虽然它们多了几 MB，但从整体来看，牺牲少量的空间来换取调试的便利，还是很值得的。

这是最难解决的问题。

scratch 作为基础镜像，Go 语言版本的 hello world 跑得很欢快，C 语言版本就不行了。或者换个更复杂的 Go 程序也是跑不起来的 ( 例如用到了网络相关的工具包 )，会遇到类似于下面的错误:

standard_init_linux.go:211: exec user process caused "no such file or directory"

从报错信息可以看出缺少文件，但没有指明到底缺少哪些文件，其实这些文件就是程序运行所必需的动态库 ( dynamic library )。

举个例子，给一个 Dockerfile:

FROM gcc AS mybuildstage
COPY hello.c .
RUN gcc -o hello hello.c

FROM alpine
COPY --from=mybuildstage hello .
CMD ["./hello"]

启动容器出现了错误:

standard_init_linux.go:211: exec user process caused "no such file or directory"

前面提到 scratch 镜像作为 C 语言程序的基础镜像时，程序运行报错的原因是 scratch 镜像中缺少动态库文件。

Alpine 镜像与 scratch 镜像类似。

Alpine 使用的也是动态库，毕竟它的设计目标之一就是占用更少的空间。

但 Alpine 使用的标准库与大多数发行版不同，它使用的是 musl libc，这个库相比于 glibc 更小、更简单、更安全， 但是与大家常用的标准库 glibc 并不兼容 。

不用 musl libc 代替 glibc 的原因是，glibc 有很多扩展库，并且很多程序都用到了这些扩展库，但 musl libc 不包含这些扩展库。

也就是说， 如果想让程序跑在 Alpine 镜像中，必须在编译时使用 musl libc 作为动态库 。

为了生成一个与 musl libc 链接的二进制文件，有两条路:

1. 某些官方镜像提供了 Alpine 版本，可以直接拿来用；
2. 还有些官方镜像没有提供 Alpine 版本，我们需要自己构建。

对于解释型语言来说，如果程序仅用到了标准库或者依赖项和程序本身使用的是同一种语言，且无需调用 C 库和外部依赖，那么使用 Alpine 作为基础镜像一般是没有啥问题的。

一旦程序需要调用外部依赖，情况就复杂了，想继续使用 Alpine 镜像，就得安装这些依赖。

根据难度可以划分为三个等级:

1. 简单: 依赖库有针对 Alpine 的安装说明，一般会说明需要安装哪些软件包以及如何建立依赖关系。但这种情况非常罕见，原因前面也提到了，Alpine 的软件包数量比大多数流行的发行版要少得多。
2. 中等: 依赖库没有针对 Alpine 的安装说明，但有针对别的发行版的安装说明。可以通过对比找到与别的发行版的软件包相匹配的 Alpine 软件包 ( 假如有的话 )。
3. 困难: 依赖库没有针对 Alpine 的安装说明，但有针对别的发行版的安装说明，但是 Alpine 也没有与之对应的软件包。这种情况就必须从源码开始构建！

最后一种情况最不推荐使用 Alpine 作为基础镜像，不但不能减小体积，可能还会适得其反，因为你需要安装编译器、依赖库、头文件等等……更重要的是，构建时间会很长，效率低下。

如果非要考虑多阶段构建，就更复杂了，你得搞清楚如何将所有的依赖编译成二进制文件，想想就头大。因此一般不推荐在解释型语言中使用多阶段构建。

有一种特殊情况会同时遇到 Alpine 的绝大多数问题: 将 Python 用于数据科学。

numpy 和 pandas 之类的包都被预编译成了 wheel。wheel 是 Python 新的打包格式，是二进制格式，用于替代 Python 传统的 egg 文件，可以通过 pip install <package_name> 直接安装。

但这些 wheel 都绑定了特定的 C 库，这就意味着在大多数使用 glibc 的镜像中都可以正常安装，但 Alpine 镜像就不行，原因前面已经说过了。

如果非要在 Alpine 中安装，需要安装很多依赖，从头构建，耗时又费力。

也不是所有 Python 程序都不推荐用 Alpine，至少 Python 用于数据科学时不推荐使用 Alpine，其他情况还是可以试一试 Alpine 的。

如果实在不想折腾，可以选择一个折衷的镜像 <image_name>:slim。slim 镜像一般都基于 Debian 和 glibc，删除了许多非必需的软件包，优化了体积。比如:

• python:3.7.9-slim-buster 镜像大小 40.37 MB；
• python:3.7.9-buster 镜像大小 321.27 MB。

如果构建过程中需要编译器，那么 slim 镜像不适合，除此之外大多数情况下还是可以使用 slim 作为基础镜像的。